Test evidence:
GitHub Actions
GHCR resulting versions

1. Partial versioning pinning does not work for ASF, as ASF very loosely follows semver versioning, and we do not support other versions than latest stable and pre-release anyway. The only objective of A.B.C.D tags is for archival purposes and easy fallback, like what can be found in GitHub releases. Not going to happen, besides, it'd require docker container being re-built anyway, and in this case people can just look up the version they intend to run instead.

2. https://github.com/JustArchiNET/ArchiSteamFarm/wiki/Docker

Due to the fact that the latest image comes with capability of auto-updates, it includes bare OS with OS-specific linux ASF version, contrary to all other tags that include OS with .NET runtime and generic ASF version. This is because newer (updated) ASF version might also require newer runtime than the one the image could possibly be built with, which would otherwise require image to be re-built from scratch, nullifying the planned use-case.

ASF already used to have generic auto-update version and it was complete disaster - the version would very often stop working due to the fact that newer ASF version required .NET runtime not to be found on target machine. It was changed for a very good reason, this is why currently ASF offers generic versions in all tags other than latest, but only latest has capability of auto-updates. It's not a scenario I'm willing to support, people that believe they know better can prepare such docker container themselves. In comparison, you could grab latest from several years ago, and it'd update and work properly, even across several major .NET releases and ASF versions that happened in the meantime. Your suggestion is doomed to last no longer than through a single major .NET version, and that assumes ASF will not require newer patch runtime in the meantime, and very often it does due to security updates.

Generic users can run released tag instead and rebuild as often as they like.

@JustArchi Not sure I follow your argument. released is built against pre-releases. As someone who is more interested in the latest stable and released version, it is not very helpful. As for .Net version, not completely sure but I thought the entire point of having docker is to isolate host dependencies from the app, and docker images should have everything self-contained, which means working .Net version matching the released app version?

If you're against Major.Minor or Major tags, I have no problem with removing those. But I think the generic tag is kind of useful as a middle-ground between latest and released.

generic being latest without auto-updates I can permit, as that's the only part that makes sense. Very limited usability considering people would usually just pick released instead but it makes sense so acceptable and can be considered.

As for .Net version, not completely sure but I thought the entire point of having docker is to isolate host dependencies from the app, and docker images should have everything self-contained, which means working .Net version matching the released app version

And that's the exact problem I have with enabling auto-updates. As it is right now, latest tag does NOT follow docker guidelines, because it has auto-updates enabled, and that's done against common sense because users using docker in inappropriate way expect it. All other tags do follow docker guidelines, and that's precisely why they don't have auto-updates enabled, because generic version of ASF does NOT guarantee it'll run in the same docker environment some old ASF version was built in.

So you can see why generic with auto-updates will just not happen. Docker is not the right tool for that.

Sure. When I said auto-updates, I meant updating with external tools such as watchtower, not the ASF's internal auto-update mechanism. Thanks for adding this.

Great, then we're on the same page here. Adding generic tag which will be available shortly.

FYI I decided to rebrand this from generic to stable, as our tags follow release type rather than build type. In theory, all but latest tags are generic, so that could leave false impression.

stable tag is now available in repositories and includes current stable version. This makes it even more obvious that it's the same as released just without pre-releases.